Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-088

Internet Message Format | 1995-06-07 | 51.4 KB | [TEXT/R*ch]

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-088
Date: Mon, 13 Mar 1995 13:22:32 +0100 (MET)

C.S.M.P. Digest             Mon, 13 Mar 95       Volume 3 : Issue 88

Today's Topics:

        Asynchronous Programming?
        Distinguishing QT-compressed PICTs
        Getting TEHandle from dialog item number
        How to get a CLUT from a PICT file?
        I need gWorlds??
        IP  --> Name translation
        LDEFs - HOW?
        ShowDragHilite -- a real drag?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From Said Kobeissi <[e-mail]>
Subject: Asynchronous Programming?
Date: 23 Feb 1995 15:57:07 GMT
Organization: TOGETHER INTERNET SERVICES

Hi all,

  Can anyone give me a pointer to examples or references for
learning how to program asynchronous routines? I want to do
some multitasking but being new to the Mac, have no idea where
to start.

Greatly aprpeciate it..
  Said

[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Fri, 24 Feb 1995 02:44:18 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3iib8j$[e-mail]> Said Kobeissi <[e-mail]> writes:
>  Can anyone give me a pointer to examples or references for
>learning how to program asynchronous routines?

look in develop issue 17 (March 1994) "Concurrent programming with the Thread
Manager", particularly "Thread Blocking I/O", on page 90.

develop is on the Reference Library volume of the Developer's CD, and is
also available separately from APDA.  I would ignore the article on the
Thread Manager in a recent Mactech.

Also, check out a good theory of computing book on state machines. The problem
with using the Thread Manager with asynchronous routines is:

o If you use pre-emptive threads, you won't run on a PowerMac, and you'll
still have the usual resource problems that interrupt routines have on the
mac.

o If you use only co-operative threads, then your i/o completion routine
will mostly just set some thread to "ready" and it will push things along
at the next co-operative thread Yield(). This can be a problem, since
this thread will be competing for time with your main thread, which is
calling WaitNextEvent, which takes a larger fraction of a second each time
it is called. In addition, if the user holds the mouse button down over a menu
or a control, WaitNextEvent won't get called until the user lets go, which
can be a _long_ time.

- -------- Here is what I do

pre-allocate resources, and make a "freelist" of them using the Enqueue()
system call.

>From my completion routine, I grab resources with Dequeue(). Enqueue()
and Dequeue() are specifically safe to call at interrupt time.  The system
checks the state of the keyboard and mouse at interrupt time, and Dequeues()
an EventRecord from a low-memory linked list of free event records, fills
it in, and Enqueues() it on the event queue.  I use a similar technique,
with a private event queue, that I poll at WaitNextEvent time, to see if
the interrupt driven side of my program has any messages for the user
interface side of the program.

My completion routines generally start more async i/o, but they also start
up "deadman" VBL tasks, which if the VBL fires, KillIO()s the async i/o
and enters an error recovery in the completion routine state machine. If the
i/o completes first, the i/o completion routine disables the VBL.
No race condition is possible, since if the i/o has completed, the KillIO
will do nothing, but if the KillIO comes in before the i/o is complete, the
i/o will be cancelled.

I'm the only guy in the world with

o a Logitech Cyberman x,y,z,roll,pitch,yaw joysitck,

o a Kurta serial tablet,

o an X-10 CP290 Home Control interface

on my mac, all running off of my own drivers.
--
- ------- <mail-to:[e-mail]> ----------
There is no sight finer than that of the planet Earth in your rearview mirror.



---------------------------

>From [e-mail] (Mark D. Gerl)
Subject: Distinguishing QT-compressed PICTs
Date: 24 Feb 1995 05:19:23 GMT
Organization: George Washington University

Here is my question:  Without requiring the presence of QT, how do I
determine that a particular PICT file IS QT compressed (so I can skip it
if QT is NOT installed)?  In other words, how do I distinguish a valid
1-bit B&W pict from a QT-compressed one?

Thanks!

Mark

- --------------------------------------------------------------------------
 Mark D. Gerl        | "The key to immortality is first living a life worth
 [e-mail]    |  remembering"                    - Brandon Bruce Lee
- --------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 24 Feb 1995 22:22:21 -0500
Organization: America Online, Inc. (1-800-827-6364)

>Here is my question:  Without requiring the presence of QT, how do I
>determine that a particular PICT file IS QT compressed (so I can skip it
>if QT is NOT installed)?  In other words, how do I distinguish a valid
>1-bit B&W pict from a QT-compressed one?

Straight from d e v e l o p:
The key to your question is "sit in the bottlenecks." If the picture
contains any QuickTime-compressed images, the images will need to pass
through the StdPix bottleneck. This is a new graphics routine introduced
with QuickTime. Unlike standard QuickDraw images, which only call StdBits,
QuickTime-compressed images need to be decompressed first in the StdPix
routine. Then QuickDraw uses StdBits to render the decompressed image. So
swap out theQuickDraw bottlenecks and put some code in the StdPix routine.
If it's called when you call DrawPicture, you know you have a compressed
picture. To determine the type of compression, you can access the image
description using GetCompressedPixMapInfo. The cType field of the
ImageDescription record will give you the codec type. See the
CollectPictColors snippet on this issue's CD and "Inside QuickTime and
Component-Based Managers" in develop Issue 13, specifically pages 46 and
47, for more information on swapping out the bottlenecks.

---------------------------

>From [e-mail] (Jeff Beeghly)
Subject: Getting TEHandle from dialog item number
Date: 25 Feb 1995 21:26:09 GMT
Organization: University of Washington


I have a dialog that contains several TextEdit items.  The items were
created in ResEdit, not on the fly by calling TENew.

My problem:  In the dialog filter I'm writing, I need to be able to
access several of the TE fields (I need to Activate & DeActivate).

I can't just use SelIText & GetIText because I need the TEHandle of a
particular field.

Right now I can access the CURRENT TE field by using
((DialogPeek )theDialog)->textH, but this only applies to the current field.

Ideally, I'd like to find (or create) a call that does

theTEHndl = TEHFromDialogNumber(theDialog, theNumber);

where theTEHndl is a TEHandle, theDialog is a DialogPtr, and theNumber is
a short (it's the item number).

I have THINK Ref, and I've read through the TextEdit, Dialog Manager, and
Control manager sections.  The stuff in the TextEdit section all seem to
require a TEHandle of the item in question, but since I am not creating
the TE fields on the fly, I don't have the TEHandles.  My goal:  Find out
how to get a TEHandle from a dialog index number.

Any help would be EXTREEMLY helpful at this point....

Thanks in advance,


Jeff


+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 25 Feb 1995 23:52:02 GMT
Organization: University of Michigan

Jeff Beeghly, [e-mail] writes:
 > My problem:  In the dialog filter I'm writing, I need to be able to
 > access several of the TE fields (I need to Activate & DeActivate).

There are 2 ways to write dialogs, with ModalDialog() or a modeless dialog
(this includes movable modal for most intents/purposes) using
DialogSelect().
ModalDialog offers a filterProc for you to intercept events, but you can
always return FALSE to let the Dialog Mgr handle it -- but Modal Dialogs
should only need to be activated once! You are not supposed to switch out
of them when they are up.

If you have a modeless dialog, then it may need to be
activated/deactivated
several times across its lifetime. However, DialogSelect() should already
handle (and eat) the activate events. Note that you dont write a filter
function for DialogSelect... you handle it through your main event loop.


 > I can't just use SelIText & GetIText because I need the TEHandle of a
 > particular field.
 >
 > Right now I can access the CURRENT TE field by using
 > ((DialogPeek )theDialog)->textH, but this only applies to the current
field.
 >
 > Ideally, I'd like to find (or create) a call that does
 >
 > theTEHndl = TEHFromDialogNumber(theDialog, theNumber);
 >
 > where theTEHndl is a TEHandle, theDialog is a DialogPtr, and theNumber
is
 > a short (it's the item number).

Each Dialog has only 1 TERec allocated for it because you are only
supposed
to have one active text field in a window. When the user tabs between
items
or clicks in a new text field, the Dialog Mgr resets the ((DialogPeek)
theDialog)->textH field to be a text record for the new active field.

Because there is little need to modify the TERec of inactive items, there
is
little way to do this beyond the GetIText(), SetIText(), and SelIText()
functions
provided. If you *need* to, you can twiddle the given TERec, but I have
done
lotsa custom dialog stuff and never needed to.

 > I have THINK Ref, and I've read through the TextEdit, Dialog Manager,
and
 > Control manager sections.  The stuff in the TextEdit section all seem
to
 > require a TEHandle of the item in question, but since I am not
creating
 > the TE fields on the fly, I don't have the TEHandles.  My goal:  Find
out
 > how to get a TEHandle from a dialog index number.

Unfortunately TR is not much help, cuz the information is scattered in
bit and
pieces. You might try NIM-Mac Toolbox Essentials... it is a total rewrite
of the
necessary information.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 25 Feb 1995 21:43:34 -0500
Organization: America Online, Inc. (1-800-827-6364)

> My goal:  Find out
> how to get a TEHandle from a dialog index number.

The Dialog Manager only creates one TEHandle for the entire dialog.  When
an edit text item is activated, the Dialog Manager munges the TEHandle for
the dialog to use that item's data.  The item_h returned by GetDItem for
each edit text item is merely a handle with text that the Dialog Manager
puts in the TEHandle's hText field.

-Jordan

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Beeghly)
Date: 27 Feb 1995 00:32:50 GMT
Organization: University of Washington

Matt Slot <[e-mail]> writes:

>There are 2 ways to write dialogs, with ModalDialog() or a modeless dialog
>(this includes movable modal for most intents/purposes) using
>DialogSelect().
>ModalDialog offers a filterProc for you to intercept events, but you can
>always return FALSE to let the Dialog Mgr handle it -- but Modal Dialogs
>should only need to be activated once! You are not supposed to switch out
>of them when they are up.

>If you have a modeless dialog, then it may need to be
>activated/deactivated
>several times across its lifetime. However, DialogSelect() should already
>handle (and eat) the activate events. Note that you dont write a filter
>function for DialogSelect... you handle it through your main event loop.


I am using a custom filter proc, however, the reason I want to activate &
de-activate TE items is that I'm creating dialogs that act like the
standard "Save file" dialog box.

In a dialog box I'm working on, there are two lists boxes and two TE
fields.  Pressing TAB switches the focus.  In my dialog box, it goes TE1,
TE2, ListBox1, ListBox2.  When LB1 or LB2 have the focus, a rectangle
outlines the list box (please see NIM, More Toolbox Essentials: List
Boxes for further info), and I need to de-select the current TE field.



+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 27 Feb 1995 00:49:18 GMT
Organization: University of Michigan

Jeff Beeghly, [e-mail] writes:
 > I am using a custom filter proc, however, the reason I want to
activate &
 > de-activate TE items is that I'm creating dialogs that act like the
 > standard "Save file" dialog box.

You should only have to deactivate and then activate the current text
field,
which is accessible thru the textH field of the DialogPeek (the other
field
is already deactivated).

Or, you might try to see if you can tweak the textH and editField info
directly, and use it to indicate the current keyboard focus for both
text AND and lists. (My impression is that the Dialog Mgr wont like this,
but it may be worth a shot.)

---------------------------

>From Martin Cowley <[e-mail]>
Subject: How to get a CLUT from a PICT file?
Date: 20 Feb 1995 19:32:46 GMT
Organization: BITE Project, UEA

I'm putting the finishing touches to a hypermedia system in C++ on Mac
and Windows that uses QuickTime and QuickTime for Windows.  It uses the
QuickTime DisplayPictureFromFile() function to display the picture
straight from disk, rather than reading it into memory first (which is
something I still haven't found a straightforward way of doing).  It sets
up the picture's frame from the information supplied by the
GetPictureFileHeader() function.

All my picture files have the same CLUT (optimised with Debabelizer), and
I'd like to be able to set up the CLUT from the PICT file too without
having to read the whole thing into memory first.  Does anyone know of a
good way to do this?  At the moment I'm storing the CLUT as a resource,
but this means that I have to recompile every time my CLUT changes, and
also that I need to store every possible CLUT as a resource.  Reading the
CLUT from the file would make the system far more flexible as it would be
able to deal with new CLUTs without modification.

QuickTime for Windows has a  GetPicturePalette() function which extracts
the palette from a memory-resident PICT, but then QTW also has a
GetPictureFromFile() function which sets up a picture in memory from the
disk file.  If it's not possible to get the CLUT from the file on a Mac
then I guess I'll have to read it in first, but how?  The Mac seems to
have no equivalent to QTW's GetPictureFromFile() function, and the only
relevant bit of code I've seen is in the Apple PICT File Format Notes -
it looks pretty horrendous and assumes you want to draw the picture as
you're reading it, which is not what I want to do.

Any help on this would be very much appreciated!

Thanks in advance,

Martin.

____________________________________________

Martin Cowley
Senior Research Associate
BITE Project
UEA Norwich
NR4 7TJ
UK

Email: [e-mail]
URL  : http://www.sys.uea.ac.uk/acc/photos/cowley.html

+++++++++++++++++++++++++++

>From [e-mail] (Lawson English)
Date: 24 Feb 1995 01:18:22 GMT
Organization: Primenet

Martin Cowley ([e-mail]) wrote:
: I'm putting the finishing touches to a hypermedia system in C++ on Mac
: and Windows that uses QuickTime and QuickTime for Windows.  It uses the
: QuickTime DisplayPictureFromFile() function to display the picture

[snipt]

: QuickTime for Windows has a  GetPicturePalette() function which extracts
: the palette from a memory-resident PICT, but then QTW also has a
: GetPictureFromFile() function which sets up a picture in memory from the
: disk file.  If it's not possible to get the CLUT from the file on a Mac
: then I guess I'll have to read it in first, but how?  The Mac seems to
: have no equivalent to QTW's GetPictureFromFile() function, and the only
: relevant bit of code I've seen is in the Apple PICT File Format Notes -
: it looks pretty horrendous and assumes you want to draw the picture as
: you're reading it, which is not what I want to do.

What you are looking for is in NIM:Imaging with QUickDraw, pp 7-13&14.

Assuming that you've gotten a file reference number for the PICT file:

+++++++++++++++++++++++++++
Drawing a Picture Stored in a 'PICT' File

Listing 7-2 illustrates an application-defined routine, called
MyDrawFilePicture, that uses File Manager routines to retrieve a picture
saved in a 'PICT' file. The MyDrawFilePicture routine takes a file
reference number as a parameter.

Listing 7-2  Opening and drawing a picture from disk

FUNCTION MyDrawFilePicture(pictFileRefNum: Integer; destRect: Rect): OSErr;
CONST
  cPicFileHeaderSize = 512;
VAR
  myPic:        PicHandle;
  dataLength:        LongInt;
  err:        OSErr;
BEGIN      {This listing assumes the current graphics port is set.}
  err := GetEOF(pictFileRefNum,dataLength);      {get file length}
  IF err = noErr THEN BEGIN
    err := SetFPos(pictFileRefNum,fsFromStart,
              cPicFileHeaderSize);   {move past the 512-byte 'PICT' }
                                     { file header}
    dataLength := dataLength - cPicFileHeaderSize;
                        {remove 512-byte }
                        { 'PICT' file header from file length}
    myPic := PicHandle(NewHandle(dataLength)); {allocate picture handle}
    IF (err = noErr) & (myPic <> NIL) THEN BEGIN
      HLock(Handle(myPic));     {lock picture handle before using FSRead}
      err := FSRead(pictFileRefNum,dataLength,Ptr(myPic^));    {read file}
      HUnlock(Handle(myPic));   {unlock picture handle after using FSRead}
      MyAdjustDestRect(myPic,destRect);   {see Listing 7-7 on page 7-18}
      DrawPicture(myPic,destRect);
      IF QDError <> noErr THEN
        ; {likely error is that there is insufficient memory}
      KillPicture(myPic);
    END;
  END;
  MyDrawFilePicture := err;
END;

In code not shown in Listing 7-2, this application uses the File Manager
procedure StandardGetFile to display a dialog box that asks the user for
the name of a 'PICT' file; using the file system specification record
returned by StandardGetFile, the application calls the File Manager
function FSpOpenDF to return a file reference number for the file. The
application then passes this file reference number to MyDrawFilePicture.
Because every 'PICT' file contains a 512-byte header for application-
specific use, MyDrawFilePicture uses the File Manager function SetFPos
to skip past this header information. The MyDrawFilePicture function then
uses the File Manager function FSRead to read the file's remaining
bytes -those of the Picture record- into memory.
The MyDrawFilePicture function creates a handle for the buffer into which
the Picture record is read. Passing this handle to the DrawPicture
procedure, MyDrawFilePicture is able to replay onscreen the commands
stored in the Picture record.
For large 'PICT' files, it is useful to spool the picture data from disk as
necessary instead of reading all of it directly into memory.
+++++++++++++++++++++++++++++++++++++++++++++

Once you have the PICT file in memory, you can use the GetPictInfo
function to gather info about a single picture:

(NIM:Imaging, pp 7-47&48)
++++++++++++++++++++++++++++++++++++++++
GetPictInfo

Use the GetPictInfo function to gather information about a single picture.
FUNCTION GetPictInfo (thePictHandle: PicHandle;
               VAR thePictInfo: PictInfo; verb: Integer;
               colorsRequested: Integer;
               colorPickMethod: Integer;
               version: Integer): OSErr;

thePictHandle: A handle to a picture.
thePictInfo: A pointer to a PictInfo record, which will hold information
about the picture. The PictInfo record is described on page 7-32.
verb  A value indicating what type of information you want GetPictInfo to
return in the PictInfo record. You can use any or all of the following
constants or the sum of the integers they represent:

        CONST
        returnColorTable            = 1;    {return a ColorTable record}
        returnPalette            = 2;    {return a Palette record}
        recordComments            = 4;    {return comment information}
        recordFontInfo            = 8;    {return font information}
        suppressBlackAndWhite
                    = 16;    {don't include black and }
                        { white with returned colors}
++++++++++++++++++++++

For more info, look at NIM:Imaging, chapter 7.

Hope that this helps...


--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

---------------------------

>From [e-mail] (Alan Long)
Subject: I need gWorlds??
Date: 22 Feb 1995 06:14:10 MST
Organization: Motorola

     I'm new to Mac programming, and found during development of my first
(simple!) application that updating the screen after being revealed from
behind another window is a real pain.  It's difficult to keep track of
what should be on-screen and what should not, at any point in time, so my
screen update function became almost as complicated as the rest of the
program.

     Is the answer to use the famous gWorlds (I haven't yet crossed
swords with these)?  I get the feeling that it is preferable to always
write to an off-screen gWorld and then use CopyBits to write to my
visible screen.  A screen update can then presumably be accomplished by
simply copying from off-screen.

     Is this the best general solution to my updating problem?

Regards,
Alan

+++++++++++++++++++++++++++

>From Gordon Graber <[e-mail]>
Date: 22 Feb 1995 14:51:57 GMT
Organization: Drake University

In article <[e-mail]> Alan Long,
[e-mail] writes:
>behind another window is a real pain.  It's difficult to keep track of
>what should be on-screen and what should not, at any point in time, so my
>screen update function became almost as complicated as the rest of the
>program.

Perhaps you, like I, are making the the situation too complicated.  I
have found that the easiest way the update a window is to draw the entire
window.  When issuing your drawing calls, bracket them with
the BeginUpdate/EndUpdate statements.  This will allow the system to
handle exactly what part of the window actually gets drawn into.
You need not be concerned with what part of a window is, say, revealed,
because the update mechinism handles that for you
  GWorlds are not going to help you in this respect.  What gworlds will
allow you to do is set up your window, offscreen.  When  you copy the
offscreen gworld to your window, your window is drawn
"at once", without the user seeing all the drawing calls executing that
comprise the graphics inside your window.  Since you have constucted the
"content" of your window offscreen, and then copy that offscreen
"content" to your "visible" window, the user only sees one "drawing
command".
  Again it is the update mechanism that ensures that only the parts of
the window that need updating, i.e. the parts that have been uncovered,
are actually drawn into.
  Hope it helps!
Gordon Graber: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Stephen &roo Sample)
Date: Wed, 22 Feb 1995 12:34:05 -0500
Organization: RadioÖcular Stereo Systems

In article <3ifj2d$[e-mail]>, Gordon Graber
<[e-mail]> wrote:

> Perhaps you, like I, are making the the situation too complicated.  I
> have found that the easiest way the update a window is to draw the entire
> window.  When issuing your drawing calls, bracket them with
> the BeginUpdate/EndUpdate statements.  This will allow the system to
> handle exactly what part of the window actually gets drawn into.
> You need not be concerned with what part of a window is, say, revealed,
> because the update mechinism handles that for you

The other thing you can do is use the visRgn of the window
(window->visRgn) as the mask region when you update with CopyBits. This is
probably marginally faster than the method described above (fewer calls
and less memory being thrown around), but I don't have any numbers.


Ta,
   -Stephen

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 22 Feb 1995 17:58:10 GMT
Organization: NW NEXUS, Inc. -- Internet Made Easy [phone]

In article <[e-mail]>,
Alan Long <[e-mail]> wrote:
|Is this [GWorlds] the best general solution to my updating problem?

Without knowing more about your application it's hard to say, but in
general, the answer is probably not.

First, you only need to keep track of what's in the window, because
BeginUpdate will cause your drawing to be clipped to the region of your
window that needs updating.  In fact, you could draw all your data, and
Quickdraw will automatically clip things correctly.  Of course if you've
got a lot of things to draw, trap overhead may kill you, so you could
compare each item's bounds to the clip region yourself.

Second, keeping GWorlds may take a *lot* of memory.  Consider a full color
window on a 1024x768, 16bit screen.  If the window is zoomed to full size,
a GWorld would probably be around 960x750x2 or 1.44Meg.  And a 1024x768
screen isn't the biggest available, and with multiple monitors your window
could be much bigger.  And of course that's just one window, if you support
multiple windows (which, in general, you should), you'll need a GWorld
for each.  Pretty soon your memory requirements will exceed even those
of Microsoft apps. :-)

Before resorting to GWorlds, look at the design of your app and how you
keep track of your data.  Some judicious redesign may solve your problem.

Brian
--
Brian L. Matthews                    [e-mail]
  You can't have a syntax error with a hammer.

+++++++++++++++++++++++++++

>From Gordon Graber <[e-mail]>
Date: 22 Feb 1995 19:05:04 GMT
Organization: Drake University

In article <[e-mail]> Stephen
&roo Sample, [e-mail] writes:
>The other thing you can do is use the visRgn of the window
>(window->visRgn) as the mask region when you update with CopyBits. This
is
>probably marginally faster than the method described above (fewer calls
>and less memory being thrown around), but I don't have any numbers.

  Isn't this the region that the system uses through the update
mechanism, anyway?  Or are you helping the system out, in a sense, by
setting this region manually?  Can you elaborate?

Thanks,
Gordon Graber:  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 22 Feb 1995 13:08:32 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Alan Long) wrote:

>      I'm new to Mac programming, and found during development of my first
> (simple!) application that updating the screen after being revealed from
> behind another window is a real pain.  It's difficult to keep track of
> what should be on-screen and what should not, at any point in time, so my
> screen update function became almost as complicated as the rest of the
> program.

gWorlds aside, the general paradigm is to do ALL drawing in response to
update events ("live" scrolling in its various forms being a key
exception).  That means your app needs to keep track of what should be
drawn where (which is fairly natural:  if it were to read the same data
>From a file it would have to know what should be drawn where).  Then upon
update, the easy way is to draw everything.  Slightly more complex (and
perhaps lots faster) is to draw only things which intersect the area of
the window being drawn.  And using gWorlds is a little more complex, but
in many ways better (the user doesn't see things being drawn--she sees the
result).

>      Is the answer to use the famous gWorlds (I haven't yet crossed
> swords with these)?  I get the feeling that it is preferable to always
> write to an off-screen gWorld and then use CopyBits to write to my
> visible screen.  A screen update can then presumably be accomplished by
> simply copying from off-screen.
>
>      Is this the best general solution to my updating problem?

Often, yes.  Not always.

Suggest you study the code samples (unfortunately, that means the more
complex ones).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Fri, 24 Feb 1995 19:31:29 +1300 (NZDT)
Organization: (none)

[e-mail] (Alan Long) writes:
>      I'm new to Mac programming, and found during development of my first
> (simple!) application that updating the screen after being revealed from
> behind another window is a real pain.  It's difficult to keep track of
> what should be on-screen and what should not, at any point in time, so my
> screen update function became almost as complicated as the rest of the
> program.
>
>      Is the answer to use the famous gWorlds (I haven't yet crossed
> swords with these)?  I get the feeling that it is preferable to always
> write to an off-screen gWorld and then use CopyBits to write to my
> visible screen.  A screen update can then presumably be accomplished by
> simply copying from off-screen.
>
>      Is this the best general solution to my updating problem?

The general solution is to maintain some sort of data structure that
describes the screen contents, and have a single Draw() function that
draws the whole mess (or better: just the contents of a rectangular
area.

This should usually be the *only* place in your program that you draw
the contents of your window.  Anywhere else that you really think you want
to change what's on the screen, you should just call InvalidRect() on the
area you want to draw into, and wait for the system to send you an update
event.

This breaks down for things like feedback on mouse tracking, and other
animation, but is a good general rule, to br broken when needed.

Now, the data structure that you create to describe the screen's contents
will usually be something like a list of the objects on the screen, but
in some cases you might in fact want to have this data structure be an
off-screen GWorld.  The reason for doing this would usually be that
redrawing the screen takes too long otherwise, and not because it is
too complicated.  If you can draw it in the first place then it's usually
not too much harder to do it so you draw it on demand.

Of course, something that is very complicated to draw is probably also
slow to draw.  But we're talking *really* complicated -- like a 3D render
of a complex scene -- before that's an issue.

Bear in mind also that an offscreen GWorld can solve the window revealing
problem, but it doesn't solve the window resize problem, or the window
scrolling problem unless the offscreen GWorld is the size of the entire
document, not just the size of the window.

A Draw() routine that can on demand draw any rectangle from your document,
OTOH, solves all these problems, and that is exactly how application
frameworks such as MacApp and TCL and PowerPlant do window revealing and
resizing and scrolling (and printing, too).  All by calling a single
user-supplied Draw() routine to draw an appropriate rectangle.

Hope this helps.

-- Bruce

---------------------------

>From [e-mail] (Jude Giampaolo)
Subject: IP  --> Name translation
Date: Sun, 26 Feb 1995 12:33:57 -0500
Organization: CWRU Amoeba Project

I'm looking for a code example that takes an IP address and returns the
hostname. I would prefer Pascal, but C would be ok too.

Thanks....

--
Jude Giampaolo              Case Western Reserve University
Electrical Engineering      'There's not much to see actually,
and Applied Physics         we're inside a Chinese dragon...'
[e-mail]            [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (chris-b)
Date: Mon, 27 Feb 1995 18:37:58 +1200
Organization: HyperMedia Unit, Comp Sci, Auckland University

In article <[e-mail]>,
[e-mail] (Jude Giampaolo) wrote:

>I'm looking for a code example that takes an IP address and returns the
>hostname. I would prefer Pascal, but C would be ok too.

Here's some C to do the job. Read "MacTCP Programmer's Guide" for more info.
Most error handling is removed for clarity.


#include <MacTCP.h>

OSErr           Err;
ip_addr         IPAddr;
SInt16          IOResult;
hostInfo        HInfo;

////////////////////////////////////////
//Get IP address

    IPAddr = ??;

////////////////////////////////////////
//Open DNR

    Err = OpenResolver(nil);
    if (Err != noErr)
    {
    }

////////////////////////////////////////
//Lookup our machine name on net

    IOResult = inProgress;
    Err =
AddrToName(IPAddr,&HInfo,(ResultProcPtr)DNRResultProc,(char*)&IOResult);
    if (Err == cacheFault)
    {
        WaitFor(&IOResult);
        Err = HInfo.rtnCode;
    }

    switch (Err)
    {
        case noErr:
//Machine name (CString) in HInfo.cname
            break;

        case noNameServer:
        case authNameErr:
        case noAnsErr:
        case dnrErr:
        case outOfMemory:
            Err = CloseResolver();
            break;

        default:
            Err = CloseResolver();
            break;
   }

////////////////////////////////////////
//Close DNR

    Err = CloseResolver();
    if (Err != noErr)
    {
    }

////////////////////////////////////////

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

---------------------------

>From [e-mail] (Glenn M. Berntson)
Subject: LDEFs - HOW?
Date: Mon, 20 Feb 1995 08:50:51 -0400
Organization: Harvard University

I've been playing with lists for a while and have heard mention of LDEFs
to add functionality to lists.

How do they work?  Where can I find informtion on how to create and use an LDEF?

Any information would be greatly appreciated.

Thanks

Glenn

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 20 Feb 1995 16:29:08 GMT
Organization: University of Michigan

Glenn M. Berntson, [e-mail] writes:
 > Where can I find informtion on how to create and use an LDEF?

Look at your local Sumex mirror for a file called "sample-ldefs",
somewhere in the depths of the "dev" directory.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 20 Feb 1995 22:41:14 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
Glenn M. Berntson <[e-mail]> wrote:
>I've been playing with lists for a while and have heard mention of LDEFs
>to add functionality to lists.
>
> How do they work?  Where can I find informtion on how to create and use
> an LDEF?

The idea of definition functions is common to several of the Toolbox
managers: the menu manager uses MDEFs to draw menus; the window manager
uses WDEFs to draw windows; the list manager uses LDEFs to draw cells in
lists.  For example, the menu manager doesn't do the actual drawing of
menus itself; instead, it calls an MDEF at the appropriate time to draw a
menu.  There's the standard MDEF that draws normal text menus, but you can
write your own MDEF for, say, a tools menu or a patterns menu.

Likewise with the List Manager.  The List Manager figures out how which
cell you've clicked in, what the scroll bars should be doing, etc, but the
actual drawing of the cells is done by the LDEF.  The standard LDEF draws
strings, but you can write an LDEF to draw any kind of cell you like (lists
of icons, etc.)  The description in OldIM IV is pretty clear on how to do
this (I have no idea where it is in NIM).

Apple's original idea was that the LDEF would be a separate resource which
would contain all the code to draw a cell, but the problem is that such
things are annoying to debug, since you can't use your programming
environment to step through them as you can with regular application code.
What a lot of people do is just to make a little _stub_ of an LDEF which
only contains a machine instruction to jump into your main code; then, you
can do your debugging as usual within your program and can also access all
of your program's globals from within your pseudo-LDEF, which you can't do
>From a real LDEF  (Usual caveats about self-modifying code apply).  If you
want details on how to do this, write me, or I can post some Pascal code if
there's interest.

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.


+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Wed, 22 Feb 1995 16:23:27 -0500
Organization: Communications Accessibles Montreal, Quebec Canada

In article <[e-mail]>,
[e-mail] (Glenn M. Berntson) wrote:

> I've been playing with lists for a while and have heard mention of LDEFs
> to add functionality to lists.
>
> How do they work?  Where can I find informtion on how to create and use
an LDEF?
>
> Any information would be greatly appreciated.


An LDEF is a List Definition, it's just a little piece of code that
controls how items in a list of drawn, and highlighted...

For example, standard file uses a custom LDEF so those icons can be drawn
next to the file name.

You can get info in NIM:More Mac ToolBox, in the List Manager section...


.:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::.
|    Chris Watson                                                   |
|    [e-mail]            Hooked on foniks werkes four me!    |
|    Montreal, Canada                                               |
i:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::i

---------------------------

>From Carl R. Osterwald <[e-mail]>
Subject: ShowDragHilite -- a real drag?
Date: Wed, 15 Feb 1995 16:16:53 GMT
Organization: National Renewable Energy Laboratory

The HIG for the drag manager states that a window which will be the drop
location of a drag should be highlighted when the mouse is inside that
window.  To that end, ShowDragHilite is provided to perform this
function.  Unfortunately, it only seems to work when the region to be
highlighted is mostly white (such as Finder windows), or if the bit
depth is 1 (in which case it inverts pixels).  If graphics are
displayed in the region to be highlighted (such as when a pix map is
being displayed), ShowDragHilite does nothing.  This behaviour does not
seem to be documented in the programmer's guide.

Also, if scrolling is to take place, one is supposed to call
DragPreScroll and DragPostScroll so that the highlighting can be erased
before scrolling takes place, and then restored afterwards.  It has
been my experience that these routines may be buggy in that in certain
scrolling situations, the highlighting is not erased properly and you
end up with a series of bars running across your nice clean window.
This seems to happen about 5% of the time.

The only solution I can see is to dedicate a 3-pixel border around the
outside the display portion of the window for drag highlighting (inside
of the scroll bars, of course).  Doing this also gets around the
scrolling problem because the highlighting never has to be erased.

In summary, it would seem that the drag manager was designed and
optimized for the Finder and displays of text, not graphics.
Any comments?

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 16 Feb 1995 08:20:00 GMT
Organization: NW NEXUS, Inc. -- Internet Made Easy [phone]

In article <[e-mail]>,
Carl R. Osterwald  <[e-mail]> wrote:
|Unfortunately, it [ShowDragHilite] only seems to work when the region to be
|highlighted is mostly white (such as Finder windows), or if the bit
|depth is 1 (in which case it inverts pixels).

It actually works, it just doesn't look that way. :-)  ShowDragHilite sets
hilite mode and inverts the region.  This means that in a multi-bit
environment, any pixel that is the background color (white, unless you've
changed it) is replaced with the hilite color (normally set via the Color
control panel).  So if your window is completely filled with non-white
(or non-background color) pixels, ShowDragHilite will appear to do nothing.

|Also, if scrolling is to take place, one is supposed to call
|DragPreScroll and DragPostScroll so that the highlighting can be erased
|before scrolling takes place, and then restored afterwards.  It has
|been my experience that these routines may be buggy in that in certain
|scrolling situations

They use updateRgn so if you're doing something strange with it, or not
calling BeginUpdate/EndUpdate or ScrollRect in the normal fashion, it may
not work.  I've never seen a problem with it though.

|The only solution I can see is to dedicate a 3-pixel border around the
|outside the display portion of the window for drag highlighting (inside
|of the scroll bars, of course).  Doing this also gets around the
|scrolling problem because the highlighting never has to be erased.

Or you could overwrite the outer 3 pixels with the diagonal stripes pattern
or draw in the hilight color directly (instead of just inverting in the
hilite mode).  If your window can contain any colors, then it will always
be possible to construct a graphic that is unchanged by any hiliting in
the window itself.

Hmm, just had a thought.  Maybe you could use a set of diagonal patterns
to make a "marching ants" hilighting.  I believe the Drag and Drop HIG
mentions "marching ants" marquees for when a simple 50% gray pattern outline
might not be distinguishable from the stuff in the window, so it would make
sense to use a similar thing when ShowDrawHilite hilighting might not be
distinguishable from the contents of the window.  I'll have to remember
that. :-)

|In summary, it would seem that the drag manager was designed and
|optimized for the Finder and displays of text, not graphics.
|Any comments?

ShowDragHilite and friends provide a simple way to get the standard behavior
when your window contains some stuff over the background color, which is
pretty common.  If you have something different, you may not be able to use
the drag manager provided routines for scrolling and highlighting.  Think of
ShowDragHilite and friends as helper functions that provide the "90%"
behavior.  If you need the "10%" behavior, you have all of Quickdraw to fall
back on.

Brian
--
Brian L. Matthews                    [e-mail]
  You can't have a syntax error with a hammer.

+++++++++++++++++++++++++++

>From Malcolm Pradhan <[e-mail]>
Date: 16 Feb 1995 17:09:18 GMT
Organization: Section on Medical Informatics, Stanford University

In article <[e-mail]> Carl R. Osterwald,
[e-mail] writes:
>Also, if scrolling is to take place, one is supposed to call
>DragPreScroll and DragPostScroll so that the highlighting can be erased
>before scrolling takes place, and then restored afterwards.  It has
>been my experience that these routines may be buggy in that in certain
>scrolling situations, the highlighting is not erased properly and you
>end up with a series of bars running across your nice clean window.
>This seems to happen about 5% of the time

 I also thought this was the case when I was getting all sorts of
junk thanks to these calls. I was even more suspicious when I discovered
that the Finder doesn't use these calls, it erases the DragHilite and
redraws it each time. Unusually ugly for the Finder.

 However, after I finished my app I have not had this trouble. It seems
that the DragPre/PostScroll are easily confused, for example during
debugging. I'm not convinced that these are buggy in normal use but
they aren't reliable during development.


 Regards,
 Malcolm

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: Thu, 16 Feb 1995 16:22:46 GMT
Organization: National Renewable Energy Laboratory

In article <3hv1rg$[e-mail]> Brian L. Matthews,
[e-mail] writes:

>They use updateRgn so if you're doing something strange with it, or not
>calling BeginUpdate/EndUpdate or ScrollRect in the normal fashion, it
>may not work.  I've never seen a problem with it though.

This is probably what I am seeing--I do have to monkey with the
updateRgn.

>Or you could overwrite the outer 3 pixels with the diagonal stripes
>pattern or draw in the hilight color directly (instead of just
>inverting in the hilite mode).  If your window can contain any colors,
>then it will always be possible to construct a graphic that is
>unchanged by any hiliting in the window itself.

ShowDragHilite uses only a 2 pixel outline, so I just inset the graphic
display area by this amount. The appearance of a 2 pixel border around
the content is barely noticeable, plus it avoids the scrolling problem,
so I chose this solution. Also, the time/memory it would take to redraw
window portions obliterated by the highlighting would be unacceptable
in my case.

>Hmm, just had a thought.  Maybe you could use a set of diagonal
>patterns to make a "marching ants" hilighting.  I believe the Drag and
>Drop HIG mentions "marching ants" marquees for when a simple 50% gray
>pattern outline might not be distinguishable from the stuff in the
>window, so it would make sense to use a similar thing when
>ShowDrawHilite hilighting might not be distinguishable from the
>contents of the window.  I'll have to remember that. :-)

Because I already have a marching ants border, the pattern was still
(accidently) set to this pattern when I called ShowDragHilite, so I saw
an effect similar to this.  I didn't like it because it is very
different from what one sees in the Finder.

>|In summary, it would seem that the drag manager was designed and
>|optimized for the Finder and displays of text, not graphics.
>|Any comments?
>
>ShowDragHilite and friends provide a simple way to get the standard
>behavior when your window contains some stuff over the background
>color, which is pretty common.  If you have something different, you
>may not be able to use the drag manager provided routines for
>scrolling and highlighting.  Think of ShowDragHilite and friends as
helper functions that provide the "90%" behavior.  If you need the
>"10%" behavior, you have all of Quickdraw to fall back on.

I agree.

+++++++++++++++++++++++++++

>From [e-mail] (Brian L. Matthews)
Date: 17 Feb 1995 18:35:43 GMT
Organization: NW NEXUS, Inc. -- Internet Made Easy [phone]

In article <[e-mail]>,
Carl R. Osterwald  <[e-mail]> wrote:
|ShowDragHilite uses only a 2 pixel outline, so I just inset the graphic
|display area by this amount.
|Because I already have a marching ants border, the pattern was still
|(accidently) set to this pattern when I called ShowDragHilite, so I saw
|an effect similar to this.  I didn't like it because it is very
|different from what one sees in the Finder.

Although I haven't tried it, this would be my concern too, that it's
different enough that it might not be obvious that it means the same as
the highlight color border.  I agree that the 2 pixel border is the
way to go.  As a bonus, it probably helps set off the graphic from the
window even when the window isn't drag hilited.

Brian
--
Brian L. Matthews                    [e-mail]
  You can't have a syntax error with a hammer.

+++++++++++++++++++++++++++

>From [e-mail] (Dave Evans)
Date: 23 Feb 1995 09:45:22 GMT
Organization: Apple Computer, Inc.

> > ... To that end, ShowDragHilite is provided to perform this
> >function.  Unfortunately, it only seems to work when the region to be
> >highlighted is mostly white ...
> >
> >Also, if scrolling is to take place, one is supposed to call
> >DragPreScroll and DragPostScroll so that the highlighting can be erased
> >before scrolling takes place, and then restored afterwards.  It has
> >been my experience that these routines may be buggy ...

Hello,
Let me answer some comments about the DragHilite routines in the Drag
Manager toolbox.  First, the general rule for drag hilites is to provide
the best feedback for your users.  You may need to customize the Drag
and Drop Guidelines to fit your interface, and in some cases the
DragHilite routines may not meet your needs.

Specifically, the ShowDragHilite routine will only work correctly if
the window's background color is white or a very light gray.  On a darker
gray background, I recommend you draw our own drag hilite in a very dark
grey and restore to your background color manually.  This should be
easy to implement.

The DragPreScroll and DragPostScroll routines should work fine.  Be
careful with your port's clip region -- if you modify this during
your scroll the drag scroll routines might leave bits behind.

For best scroll appearance, however, I recommend using an offscreen
port for your drawing -- just use the show and hide hilite routines
in this port -- then update to the screen for flicker free scrolling.

And the reason the Finder doesn't use the DragPreScroll and DragPostScroll
routines is because:
  1. They don't use offscreen drawing (probably to use minimal memory)
  2. The Drag Manager and Finder version 7.1.x were developed concurrently
  3. and Francis, the fabulous Finder Engineer, promised he was going to
use
     them but never got around to adding them before finishing the
Finder...
     everyone in unison now: "bad Francis..."

Thank You,
Dave Evans
not a Finder engineer

- --
Apple Computer, Inc. pays the bills but doesn't necessarily endorse
what I put in writing.  (especially after 1 am)

---------------------------

End of C.S.M.P. Digest
**********************